PCT/EP 00/ U43bb 



"J 1 K . 



BUNDEs£ePUBLIK DEUTS#HLAND 



9328 

EPO- Munich 
15 




1 a Juni 2000 



Prioritatsbescheinigung uber die E 
einer Patentanmeldung 



RECD 0 7 JUL 



WIPQ 

hreichuny 



POT 




Aktenzeichen: 
Anmeldetag: 



Anmelder/lnhaber: 
Bezeichnung: 

IPC: 



199 29 002.4 
24. Juni 1999 

Siemens Aktiengesellschaft, 
Munchen/DE 

Methode zur Aktualisierung von Fenster- 
grofcen bei nicht sequenzgesicherter 
Ubertragung 

H 04 L 29/06 




Die angehefteten Stiicke sind eine richtige und genaue Wiedergabe der ur- 
sprunglichen Unterlagen dieser Anmeldung. 



4^ Munchen, den 08. Juni 2000 

Deutsches Patent- und Markenamt 

Der President m 

lm Auftrag CQ 

PRIORITY ^ 

DOCUMENT £ 

SUBMITTED OR TRANSMITTED IN ^ 

COMPLIANCE WITH RULE 17.1(a) OR (b) V^J 

5 




A 9161 pat 

O3/00 
EDV-L 




THIS PAGE BLANK (uspto) 



GR 99 P 2109 




1 

Beschreibung 

Methode zur Aktualisierung von Fenstergroften bei nicht 
sequenzgesicherter Ubertragung 

5 

1. Welches technische Problem soil durch Ihre Erfindung 
gelost werden? 

2. Wie wurde dieses Problem bisher gelost? 

3. In welcher Weise lost Ihre Erfindung das angegebene 
10 technische Problem (geben Sie Vorteile an) ? 

4. Worin liegt eine Besonderheit. der Erfindung ? 
^ 5. Ausfuhrungsbeispiel [e] der Erfindung. 

Zu 1 . : 

15 Bei Kommunikationsprotokollen werden sowohl Nutzerdaten als 
auch Kontrollinformationen ubertragen. Dabei wird bei vielen 
Protokollen sicherges tellt , dafi die Nutzerdaten vollstandig 
(d. h. alle gesendeten Daten werden auch empfangen) und 
sequenzgesichert (d. h. in der richtigen vom Sender 

20 bestimmten Reihenfolge) ubertragen werden. Fur die 

Nutzerdaten wird dies oft dadurch erreicht, daJi man alle 
Nutzerdaten mit einer Sequenznummer durchnumeriert . Pakete, 
die Kontrollinformationen enthalten, werden ublicherweise 
nicht durchnumeriert, allenfalls bestimmte Klassen von 

£5 Kontrollinformationen. Werden die Nachrichten aber nun nicht 

W sequenzgesichert von der unteren Schicht ubertragen, so kann 
es zu Oberholungen der Kontrollnachrichten fuhren. Falls die 
Oberholung nicht erkannt wird, bedeutet dies fur den 
Empfanger, dafl er statt mit aktueller Kontrollinf ormation, 

30 die ihm vorliegt, mit veralteter Kontrollinf ormation 

arbeitet, da er sie fur aktueller halt. In der Regel ist 
dieses Verhalten fur diejenige Kontrollinf ormation, die 
Nachrichtenempf ang bestatigt, nicht kritisch, da diese 
Information nicht veraltet. Kritisch ist jedoch das Verwerfen 

35 aktueller Kontrollinf ormation, die die Fluftkontrolle 

betrifft, durch das Verwenden veralteter Information, da 
diese Information sehr schnell veraltet. 
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(Im Zusammenhang mit der Fluibkontrolle seien zwei 
Bezeichnungen fixiert. Unter einem Kredit, den der Empf anger 
dem Sender gewahrt, wird hier die Sequenznummef derjenigen 
Nutzdaten verstanden, die als erste nicht mehr vom Empfanger 
akzeptiert wird. Unter der FenstergrOBe wird eine Anzahl von 
Nutzdaten verstanden, die der Empfanger bereit ist 
akzeptieren. Dabei wird von der Sequenznummer aus gezahlt, 
bis zu der der Empfanger alle Nachrichten mit kleinerer 
Sequenznummer bereits erhalten und quittiert hat.) 

Insbesondere sind dynamische Fenstergroflen, die vom Empfanger 
bestimmt werden, davon betroffen. 

Diese Erfindung beschreibt, wie man das Verwerfen aktueller 
Kontrollinformation zur FluJJkontrolle vermeidet. Insbesondere 
wird beschrieben, wie man bestehende Protokolle, die das 
Problem nicht losen, dahingehend erweitern kann, dali sie 
dieses Problem losen. 

Man kdnnte meinen, dafi man dieses Problem nicht behandeln 
mufi, falls die untere Protokollschicht eine sequenzgesicherte 
Ubertragung garantiert. Will man aber mit Hilfe einer solchen 
Schicht eine Multilink-Verbindung realisieren, so hat man 
auch bei einer solchen Schicht mit Nachrichtenuberholungen zu 
rechnen. 

Zu 2 . : 

Wenn man sich darauf beschrankt, dafi der Empfanger einen 
einmal gegebenen Kredit nicht wieder zurucknehmen darf, so 
kann man leicht das oben genannte Problem losen, indem man 
Kontrollinformation, die diese Regel verletzt, einfach nicht 
bearbeitet. Dies entspricht der Losung im TCP/IP Protokoll. 
Dies beinhaltet auch den Fall konstanter FenstergroBe . 

Eine weitere einfache Moglichkeit zur Losung des Problems 
besteht darin, alle Kontrollinf ormationen durchzunumerieren 
und dann die Kontrollinf ormationen analog zu den Nutzdaten zu 
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behandeln. Dies nachtraglich bei Protokollen einzufuhren, ist 
aber schwierig, da man zur Nuiruuerierung in der Regel das 
Nachrichtenformat andern mtlflte. Dies ist aber bei der 
Erweiterung bestehender Protokolle nicht akzeptabel. 

5 

Die Moglichkeit der Riicknahme des Kredits ist bei einigen 
Protokollen, wie zum Beispiel SSCOP, eine wichtige 
Eigenschaft. Bei solchen Protokollen scheint das Problem zur 
Zeit ungelost zu sein. 

10 

Zu 3 . : 

Bei der hier angegeben Losung kann der Empfanger der 
I Kontrollnachricht stets entscheiden, ob diese von ihm 

empfangene Nachricht eine Information beinhaltet, die neuer 
15 ist, als sein aktueller Informationsstand. Dadurch kann durch 

Nachrichtenuberholung keine altere Information eine 

aktuellere Information uberschreiben . 

Urn zu entscheiden, ob die erhaltene Information neuer ist als 
20 die schon vorhandene, werden Protokollinf ormationen benutzt, 
sofern dies moglich. Kann man aufgrund der in den 
Kontrollnachrichten enthaltenen Inf ormationen die 
Sendereihenfolge nicht rekons truieren, so werden nur die 
Kontrollinformationen zusatzlich durchnumeriert, fur die dies 
^5 unbedingt notig ist. 

Zu 4 . : 

Eine Besonderheit der Erfindung liegt in der geschickten 
Kombination aus einer eventuellen Nachrichtenf ormatanderung, 
30 die kompatibel mit dem bestehenden Protokoll ist, und einer 
Analyse des Protokolls, urn beim Empfanger der 

Kontrollinformation die zeitliche Reihenfolge des Sendens der 
Kontrollinformation zu rekonstruieren. Damit kann man dann 
alte Information verwerfen. 



Zu 5 . 
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Im folgenden werden drei Ausf lihrungsbeispiele gegeben, die 
alle auf dem Protokoll SSCOP basieren. SSCOP, definiert in 
der Q.2110, setzt voraus, dafi die untere Schicht die Daten 
sequenzgesichert tibertragt. Wie in 1. ausgefuhrt, ste'llt sich 
5 hier das diskutierte Problem also nicht. Gegenwartig wird 
aber SSCOP erweitert, urn Multilink-f ahig zu werden und liber 
einer unteren Schicht zu f unktionieren, die keine 
sequenzgesicherte Ubertragung sicherstellt . Dies entspricht 
dem MSSCOP (Draft Q.2111), wie er aktuell bei der ITU 
10 diskutiert wird. Das hier diskutierte Problem wird dort 
jedoch nicht gelost. 

Ausfuhrungsbeispiel 1 : 

Die einfachste Methode besteht darin, dafl im MSSCOP der 
15 Kredit nicht mehr verringert werden darf. Dies stellt aber 
eine wesentliche Einschrankung des Protokolls dar . Beim 
Empfang einer STAT-PDU wurde man die Kredi tinf ormation 
verwerfen, wenn der empfangene Kredit kleiner als der 
aktuelle ware. 

20 

Ausfuhrungsbeispiel 2 : 

Beim MSSCOP (Draft Q.2111), wie es aktuell diskutiert wird, 
kann man allein aus der Protokollinf ormation die 
Sendereihenf olge rekonstruieren, sofern man auf die 
25 Behandlung der CREDIT-PDUs verzichtet. Diese braucht man abe 
nicht unbedingt. In diesem Beispiel braucht man keine 
Nachrichtenf ormate zu andern. 

Man braucht eine zusatzliche SSCOP Status Variable: 
VT(H), dies ist das groflte letzte Listenelement aller 
30 empfangenen STAT-PDUs und USTAT-PDUs. 

Die Bearbeitung von empfangenen POLL-PDUs und STAT-PDUs sowie 
die Verwaltung dieser neuen Statusvariablen ergibt sich aus 
den folgenden Regeln: 



35 Wenn man eine USTAT-PDU empfangt, so verwirft man die 
Kreditinf ormation, falls List Element 2 <= VT (H) ist. 
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Andernfalls bearbeitet man die Kreditinf ormation und setzt 
VT(H) = List Element 2. 

Wenn man eine STAT-PDU empfangt, verwirft die 
Kreditinf ormation, falls das letzte Listenelement 
List Element L < VT (H) . Andernfalls nutzt man die 
Kreditinf ormation und setzt VT(H) = List Element L 

Ausf uhrungsbeispiel 3 : 

Es wird gegenwartig eine Erweiterung des SSCOP und damit auch 
des MSSCOP diskutiert, die es dem Empfanger ermoglicht, eine 
STAT-PDU zu senden ohne das diese eine direkte Antwort auf 
eine POLL-PDU ist. ( Im MSSCOP wiirden diese STAT-PDUs die 
z.Zt. definierten CREDIT-PDUs ersetzen.) Damit soil dem 
Empfanger ermoglicht werden, Kreditinf ormation zu tibertragen, 
wannimmer es fur den Empfanger sinnvoll erscheint. Dazu 
generiert der Empfanger eine STAT-PDU mit der neuen 
Kreditinf ormation . Da sich zwischen dem Aussenden mehrerer 
STAT-PDU in einem Pollzyklus der Status des Empfangers nicht 
verandern muJ3 und damit das letzte List Element gliech 
bleiben kann, muli man die STAT-PDUs im selben Pollzyklus 
durchnumerieren. Ansonsten ist dies Ausf uhrungsbeispiel eine 
Erweiterung des Ausf uhrungsbeispiels 2. 

Man fuhrt den SSCOP-PDU Parameter N(SS) und die SSCOP Status 
Variable VR(SS) ein. Beim Generieren einer STAT-PDU wird 
N(SS) mit dem Wert VR(SS) gesetzt. VR(SS) ist die nachste 
STAT Sequenznummer, die die STAT-PDUs innerhalb eines 
Pollzyklus durchnumeriert. Das modifizierte STAT-PDU Format 
ist in Abbildung 1 dargestellt. Da N(SS) in ein Feld 
geschrieben wird, das momentan als Reserved gekennzeichnet 
ist, kann auch eine nicht modifizierte SSCOP Protokoll 
Maschine solch eine Nachricht verarbeiten, da sie N(SS) nicht 
bearbeitet . 

Wird eine POLL-PDU mit neuer Pollsequenznummer empfangen, so 
wird diese wie ublich behandelt. Nur bevor eine STAT-PDU 
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generiert wird, wird noch VR(SS)=0 gesetzt. Soil nun 
innerhalb eines Pollzyklus eine weitere STAT-PDU generiert 
werden, so wird dies nur noch dann getan, falls VR(SS)<255 
gilt. Andernfalls wird keine solche STAT-PDU generiert. Im 
Fall VR(SS) < 255 wird VR(SS) urn 1 erhoht und dann eine STAT- 
PDU generiert. 

Man braucht ferner noch zwei weitere SSCOP Status Variablen: 
VT(SS), dies ist die STAT-Sequenznummer der zuletzt im 
aktuellen Pollzyklus empf angenen STAT-PDU beziehungsweise 0, 
falls noch keine empfangen wurde. 

VT(H), dies ist das groflte letzte Listenelement aller a 
empf angenen STAT-PDUs und USTAT-PDUs. ^ 
Die Bearbeitung von empfangenen POLL-PDUs und STAT-PDUs sowie 
die Verwaltung dieser neuen Statusvariablen ergibt sich aus 
den folgenden Regeln: 

Wenn man eine USTAT-PDU empfangt, so verwirft man die 
Kreditinformation, falls List Element 2 <= VT (H) ist. 
Andernfalls bearbeitet man die Kreditinformation und setzt 
VT(H) = List Element 2. 

Wenn man eine STAT-PDU empfangt, so setzt man VT(SS) = 0, 
falls VT(PA) < N(PS) gilt. 

Gilt nun N(SS) < VT(SS), so verwirft man die 
Kreditinformation . 

Gilt N(SS) >= VT(SS), so setzt man VT(SS) = N(SS) und 
verwirft die Kreditinformation, falls das letzte 
Listenelement List element L < VT (H) . Andernfalls nutzt man 
die Kreditinformation und setzt VT (H) = List Element L. 
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